On Mon, Jul 10, 2017 at 2:06 PM, tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

I'm surprised reading the Gather Buffer slows the application
significantly. I would expect it to only take a few milliseconds and if
is only read every few hundred milliseconds then should only be a few
percent of the bandwidth. How are you reading the Gather Buffer? Are
you uploading a block of data as Hex values (same as Main Status)? That
should be the fastest.

It's not the reading that is slowing it down, but the running of the thread which fills the gather buffer with the data we are interested in.

I could definitely improve it, but the multiple round trip times are slowing us down for reasons I have not completely determined.

It seems a little Kludgey to use unused fields in Main Status. What if
you ever decide to add a Kanalog or SnapAmp?

Our hardware config is pretty much determined at this stage.  From our perspective there is about 200 bytes of unused data at the start of the status block, which would allow our monitor to run full-time with no additional overhead, rather than being a separate function switched on/off by the user.

 

The 8 persist variables 100-107 are currently uploaded as part of the
Main Status.

We're already using all these: 100-103 are for the usual PC comms, 104-107 we use for the most useful status info like current spindle speed, load, and I/O states.

Main Status is always completely cleared to zero and then filled in with
appropriate data so there are limited ways that you can attach data.

The global array:

int ADC_BufferIn[N_ADCS];

should allow 8 32-bit words. But the data uploaded will have 2048
subtracted so you would need to add that back in on the PC end.

These Global Variables should provide 2 more
int BitDirShadowSnap0; // direction of 14 bits, Card0
int BitDirShadowSnap1; // direction of 14 bits, Card1

No other data is placed inthe Main Status unless the boards are present.

OK, those 10 extra words are useful.  What about the virtual I/O bits?  In kmotiondef.h, there are the following decls which look like they would be transferred:

// Virtual I/O bits
extern int VirtualBits;           // Virtual I/O bits simulated in memory, use SetBit/ClearBit/SetStateBit(32-63 to reference)
 
// Virtual I/O bits Extended 1024-2047
extern int VirtualBitsEx[N_VIRTUAL_BITS_EX/32];    // 1024 Expanded Virtual Bits (1024-2047)
 
extern int BitDirShadow[2];      // direction of all 64 I/O bits

Is it OK for us to do VirtualBits = 0x123?

We don't use the bit direction setting after init, so no problem for us to use BitDirShadow if it gets transferred in the status block.

One of these days you might consider adding a callback function that is called just before sending main_status to the PC, so that intrepid users can customize it :-)

Regards,

SJH

 

Regards
TK

On 2017-07-09 13:20, Hardy Family hardy.woodland.cypress@gmail. com

[DynoMotion] wrote:
> Hi Tom,
>
> I would like to be able to use some of the fields in the MAIN_STATUS
> struct returned by the GetStatus script command, that we are not
> otherwise likely to use (no Snapamp etc.)
>
> Currently, I have a monitor function which is a Kflop program that is
> run regularly by the application which writes some data to a gather
> buffer area, then the application retrieves it and sets LEDs, DROs
> etc.
>
> Trouble is, that is a rather slow process and noticeably slows the
> application. I have modified the KMotionServer program to add an
> automatic GetStatus poll. It sends the data to a dedicated socket
> that the app connects to. The app can then be fully event driven
> because it simply waits for data to be available, rather than having
> to poll. Also, multiple independent hosts can connect and they all
> get the same status data without increasing the polling load on the
> kflop. This is useful for us because we can have distributed DROs.
> (E.g. a Raspberry Pi and a 7" touch screen monitor - about $100 in
> parts - can be used as an on-machine DRO/control panel).
>
> So what I would like to do is use some of the otherwise unused fields
> in MAIN_STATUS to send the auxiliary monitor data. The fields that we
> could use would be:
>
> typedef struct
> {
> ...
> int ADC[N_ADCS+2*N_ADCS_SNAP];
> int DAC[N_DACS];
> int PWM[N_PWMS+2*N_PWMS_SNAP];
> ...
>
> int SnapBitsDirection0; // Snap - 32 bits of I/O direction
> 1=output 16-29 GPIO only, Card 0
> int SnapBitsDirection1; // Snap - 32 bits of I/O direction
> 1=output 16-29 GPIO only, Card 1
> int SnapBitsState0; // Snap - 32 bits of state 16-29 GPIO
> 0-7 Diff 8-15 OPTO, Card 0
> int SnapBitsState1; // Snap - 32 bits of state 16-29 GPIO
> 0-7 Diff 8-15 OPTO, Card 1
>
> int KanalogBitsStateInputs; // Kanalog - 16 bits 128-143
> int KanalogBitsStateOutputs; // Kanalog - 24 bits 144-167
>
> ...
>
> int VirtualBits; // Virtual I/O bits simulated in memory
> int VirtualBitsEx0; // only upload 32 1024 Expanded Virtual
> Bits
> } MAIN_STATUS;
>
> Is there a way to jam data somewhere so that it gets sent in the
> GetStatus result, for these fields?
>
> For example, I implemented analog input using bit-banged I2C, so it
> would be nice to write the results so they could be accessed in
> ADC[0..3] on the host.
>
> Regards,
> SJH
>